There were several locations that had an immutable array, called select on it (getting back an IEnumerable) and then did a collection expression on that to get back an array. Instead, add a SelectAsPlainArray extension method on ImmutableArray that does this more efficiently.

Old way allocates iterator from IEnumerable, intermediate arrays while calculating select, and then allocated final array
New way: only allocates final array

I noticed this from a code review I was doing, and not from perf traces, so I don't have evidence that this will make a tangible difference, but every bit helps.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-Authored-By: Copilot <223556219+Copilot@users.noreply.github.com>

Co-Authored-By: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Refresh stale completion sessions when waiting for a specific item and stop negative snippet tests from forcing completion to open.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Keep the current completion session initially and only reset it after the expected item has been missing for a sustained period.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Refresh stale completion sessions earlier once they show a real but incorrect selection, and immediately force a fresh session from the current buffer state.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…318.1 (dotnet#12923)

On relative base path root
Microsoft.DotNet.Arcade.Sdk From Version 10.0.0-beta.26164.1 -> To Version 10.0.0-beta.26168.1

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

When broker-triggered completion does not recreate a session, invoke the editor's completion list command and retry from the live text view state.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… too, just in case.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fixes microsoft/vscode-dotnettools#2900

### Summary of the changes

Updated the service connection in AzDO used for DartLabTemplates. 

Fixes: Part of work for this issue:
https://dev.azure.com/dnceng/internal/_workitems/edit/10123

Team: let me know how I can best test this change

Noticed this when looking at other runs. It's been a long time since our
repo needed node to build.

…le negative values

This isn't a change in logic in TryVisitAttribute, but crucially is a change in logic at other callsites

…408.4 (dotnet#13031)

On relative base path root
Microsoft.DotNet.Arcade.Sdk From Version 10.0.0-beta.26208.2 -> To Version 10.0.0-beta.26208.4

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

[[ commit created by automation ]]

No dependency updates to commit
[[ commit created by automation ]]

We got a Roslyn bump as part of a VMR flow, so these tests can run now.

Bump the repo SDK from 10.0.105 to 10.0.106 and System.Security.Cryptography.Xml from 8.0.2 to 8.0.3 to address the active Component Governance alerts for dotnet/razor.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…420.5

On relative base path root
Microsoft.DotNet.Arcade.Sdk From Version 10.0.0-beta.26208.4 -> To Version 10.0.0-beta.26220.5

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…line/code as source of issue (dotnet#13057)

* A proposed fix for dotnet#13056

* Refactor RuntimeNodeWriter child rendering with start-index overload

Agent-Logs-Url: https://github.com/dotnet/razor/sessions/fd00e9f4-5b89-465b-947c-dbc6523b455f

Co-authored-by: dbreshears <3432571+dbreshears@users.noreply.github.com>

* Clarify first-child skip behavior in RuntimeNodeWriter

Agent-Logs-Url: https://github.com/dotnet/razor/sessions/fd00e9f4-5b89-465b-947c-dbc6523b455f

Co-authored-by: dbreshears <3432571+dbreshears@users.noreply.github.com>

* Revert RuntimeNodeWriter start-index refactor per review

Agent-Logs-Url: https://github.com/dotnet/razor/sessions/8b6f5d8d-3d22-4180-a25d-68b3eccb589c

Co-authored-by: davidwengier <754264+davidwengier@users.noreply.github.com>

* Update additional baselines

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: dbreshears <3432571+dbreshears@users.noreply.github.com>
Co-authored-by: davidwengier <754264+davidwengier@users.noreply.github.com>

This pull request updates the following dependencies

[marker]: <> (Begin:2907dbca-fa2e-42bc-f7dd-08dc0c5b4e6d)
## From https://github.com/dotnet/arcade
- **Subscription**:
[2907dbca-fa2e-42bc-f7dd-08dc0c5b4e6d](https://maestro.dot.net/subscriptions?search=2907dbca-fa2e-42bc-f7dd-08dc0c5b4e6d)
- **Build**:
[20260420.5](https://dev.azure.com/dnceng/internal/_build/results?buildId=2955579)
([311069](https://maestro.dot.net/channel/8394/github:dotnet:arcade/build/311069))
- **Date Produced**: April 20, 2026 10:07:28 AM UTC
- **Commit**:
[54892fe0f027f2f08c59cf0802a2d7f488632e2f](dotnet/arcade@54892fe)
- **Branch**:
[release/10.0](https://github.com/dotnet/arcade/tree/release/10.0)

[DependencyUpdate]: <> (Begin)

- **Dependency Updates**:
  - From [10.0.0-beta.26208.4 to 10.0.0-beta.26220.5][1]
     - Microsoft.DotNet.Arcade.Sdk

[1]: dotnet/arcade@ecdd5c6...54892fe

[DependencyUpdate]: <> (End)

- **Updates to .NET SDKs:**
  - Updates **sdk.version** to 10.0.106
  - Updates **tools.dotnet** to 10.0.106

[marker]: <> (End:2907dbca-fa2e-42bc-f7dd-08dc0c5b4e6d)

## Summary
- bump System.Security.Cryptography.Xml from 8.0.2 to 8.0.3
- update the pinned SDK/tools patch from 10.0.105 to 10.0.106
- address the active Component Governance alerts for Razor

…t#13091)

During tag helper discovery, ComponentTagHelperProducer.GetProperties() calls GetAttributes() on every property to check for [Parameter]. This triggers expensive attribute binding and NullableWalker analysis in the Roslyn compiler for each call.

Properties that are private, static, indexers, or lack a public setter will always be Ignored regardless of attributes. For non-override properties, we can skip GetAttributes() entirely.

In Speedometer's RazorEditingTests.CompletionInCohostingForComponents, tag helper discovery re-runs on every keystroke because the source assembly symbol changes per compilation. The GetAttributes() calls contribute significantly to the 281MB of CLR_BytesAllocated_NonDevenv allocations in the devhub process — particularly NullableWalker (50MB+), BoundAttribute (13MB), and related binding infrastructure.

Override properties still go through GetAttributes() since [Parameter] determines shadow-vs-passthrough behavior.

…net#13090)

* Return empty incomplete list when HTML completion fails in Razor

When the HTML language server fails to respond during Razor completion (e.g., not yet initialized on first document open), the endpoint previously continued to merge with Razor-only results. This caused users to see tag helper completions without expected HTML element completions, risking accidental wrong item commits.

DelegatedCompletionHelper.RewriteHtmlResponse already converts a null HTML response into an empty IsIncomplete list for exactly this scenario. Add an early return in HandleRequestAsync that detects this result and returns it directly, skipping the OOP call and merge step. Also make GetHtmlCompletionListAsync non-nullable since RewriteHtmlResponse always returns a value.

Partially fixes dotnet#12970
Partially fixes dotnet#9725

* Move null-for-failure handling from RewriteHtmlResponse to GetHtmlCompletionListAsync

The previous commit checked for HTML failure by pattern-matching on { IsIncomplete: true, Items: [] }, which is ambiguous — it also matches a legitimate empty HTML response. Instead, check for null directly from MakeHtmlLspRequestAsync in GetHtmlCompletionListAsync and propagate it to the caller. This avoids calling RewriteHtmlResponse with null, so its first parameter is now non-nullable and its null guard is removed.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fixes dotnet#13064

Fix formatting when RenderFragments are self closing tags. Same as the
fix a little while ago for RenderFragments in general, but I missed that
the tags could be self-closing.

…422.2 (dotnet#13085)

On relative base path root
Microsoft.DotNet.Arcade.Sdk From Version 10.0.0-beta.26220.5 -> To Version 10.0.0-beta.26222.2

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

Fixes some issues found while investigating
https://developercommunity.visualstudio.com/t/JavaScript-indentation-breaks-inside-Raz/11078750,
namely:

* We weren't logging file kind, which means replaying in
FormattingLogTest was getting different results due to different
code-gen
* We could deduce from the logs that the issue was fixed by
dotnet#12922 but if we had the SyntaxTree
to confirm, it would have either proven it at best, or at worst the
differences between the users syntax tree and our tests syntax tree
would have given us a big head start for investigation.

> [!NOTE]
> This is a codeflow update. It may contain both source code changes
from
> [the VMR](https://github.com/dotnet/dotnet)
> as well as dependency updates. Learn more
[here](https://github.com/dotnet/dotnet/tree/main/docs/Codeflow-PRs.md).

This pull request brings the following source code changes

[marker]: <> (Begin:ef36a9a7-7cd9-4ecc-b11e-f73940dcf559)

## From https://github.com/dotnet/dotnet
- **Subscription**:
[ef36a9a7-7cd9-4ecc-b11e-f73940dcf559](https://maestro.dot.net/subscriptions?search=ef36a9a7-7cd9-4ecc-b11e-f73940dcf559)
- **Build**:
[20260415.21](https://dev.azure.com/dnceng/internal/_build/results?buildId=2952522)
([310648](https://maestro.dot.net/channel/8298/github:dotnet:dotnet/build/310648))
- **Date Produced**: April 16, 2026 8:21:55 AM UTC
- **Commit**:
[ab01524bbb2ef1eea0ffaef161b3ef5686e8f256](dotnet/dotnet@ab01524)
- **Commit Diff**:
[b61c1c3...ab01524](dotnet/dotnet@b61c1c3...ab01524)
- **Branch**: [main](https://github.com/dotnet/dotnet/tree/main)

[marker]: <> (End:ef36a9a7-7cd9-4ecc-b11e-f73940dcf559)
[marker]: <> (Start:Footer:CodeFlow PR)

## Associated changes in source repos
-
dotnet/arcade@30f8bf5...1f7eece
-
dotnet/msbuild@e2ae904...12afa00
-
NuGet/NuGet.Client@779eff1...06ee0a5
-
dotnet/razor@5813e6f...5269ad3
-
dotnet/roslyn@0eca297...2396c4d
-
dotnet/sdk@7aa1db6...2eac35a
-
microsoft/vstest@5c5c4f1...4d9b368
-
dotnet/winforms@b8261ba...c1aede2

<details>
<summary>Diff the source with this PR branch</summary>

```bash
darc vmr diff --name-only https://github.com/dotnet/dotnet:ab01524bbb2ef1eea0ffaef161b3ef5686e8f256..https://github.com/dotnet/razor:darc-main-e387b998-cacc-4ca9-b329-1a51e360a64a
```
</details>

[marker]: <> (End:Footer:CodeFlow PR)

…dotnet#13092)

Parallelize HTML and Razor completion with two-phase tag helper resolution

Problem

Razor completion in cohost mode runs HTML and Razor completion requests sequentially. The Razor call blocks on HTML completing first because tag helper element completions need HTML labels to determine which tag helpers to offer. This means total latency is always HTML + Razor, even though most Razor completions don't depend on HTML results.

Solution

Run HTML and Razor completion concurrently by splitting Razor completion into two phases:

Phase 1 (runs concurrently with HTML): Returns C# completions and all Razor completions except HTML-dependent providers. Also returns a NeedsHtmlDependentPhase flag indicating whether phase 2 is needed.

Phase 2 (runs after HTML completes, only when needed): Runs only IHtmlDependentCompletionItemProvider instances, passing HTML labels for context-aware tag helper filtering. Currently, only TagHelperCompletionProvider at element positions requires this phase — attribute positions and all other providers complete entirely in phase 1.

Total latency becomes max(HTML, Razor phase 1) + phase 2 instead of HTML + Razor. Phase 2 is skipped entirely for non-element positions and for pure Blazor/component projects where no tag helpers target HTML elements.

Key changes

 - CohostDocumentCompletionEndpoint: Launches Razor phase 1 and HTML concurrently via Task.WhenAll. After both complete, conditionally calls phase 2. Merges results via MergeCompletionLists, which uses two CompletionListMerger.Merge calls — first merging the two Razor phase lists, then merging the combined Razor list against HTML. This preserves list-level metadata (Data, ItemDefaults, CommitCharacters) and gives Razor commit characters precedence.
 - IHtmlDependentCompletionItemProvider: New interface deriving from IRazorCompletionItemProvider for providers that need HTML labels. Providers that don't need HTML labels require no changes.
 - RazorHtmlDependentCompletionContext: Derived completion context that adds HtmlLabels for phase 2, wrapping an existing RazorCompletionContext instead of duplicating context resolution. Replaces the old 
ExistingCompletions parameter on RazorCompletionContext.
 - CompletionResult: New record struct returned by phase 1 containing the completion list and NeedsHtmlDependentPhase flag, allowing the cohost to skip phase 2 when unnecessary.
 - CompletionItemsResult: New readonly record struct replacing the tuple return from IRazorCompletionFactsService.GetCompletionItems.
 - IRazorCompletionFactsService / RazorCompletionListProvider: Split into GetCompletionItems (phase 1) and GetHtmlDependentCompletionItems (phase 2). Phase 1 context creation is inlined; phase 2 reuses the same context with HtmlLabels added.
 - IRemoteCompletionService / RemoteCompletionService: Added GetHtmlDependentCompletionsAsync for the phase 2 remote call. Phase 1 no longer takes existingHtmlCompletions.
 - TagHelperCompletionProvider: NeedsHtmlCompletions inspects the document's tag helper descriptors to determine if phase 2 is actually needed. Directive attribute descriptors (e.g., @Bind on <input>) are excluded, and only descriptors with TagOutputHint or HTML-targeting tag matching rules trigger phase 2. When phase 2 is not needed, element completions run in phase 1 with empty HTML labels (component completions are always included regardless).
 - TagHelperCompletionService: Lifted the IsDirectiveAttribute check from UpdateCompletions to the top of the GetElementCompletions foreach loop, filtering earlier and enabling the Blazor phase-skip optimization.
 - CompletionListMerger: Fixed inconsistent null/empty guard on second parameter; replaced LINQ Concat().ToArray() with collection expression spread for efficient codegen on both .NET Framework and .NET Core.

Testing

 - Two new cohost completion tests verify [OutputElementHint] behavior: a tag helper with [OutputElementHint("strong")] appears when HTML completions include "strong" and is absent when they don't.
 - Updated existing RazorCompletionListProviderTest element test to include an HTML-targeting tag helper alongside a component, exercising the phase-skip logic.

Observed timing improvements from I saw locally from bringing up completion in various locations:

| # | HTML | Razor | HtmlDependent | Overall | Saved |
 |---|------|-------|---------------|---------|-------|
 | 1 | 559 ms | 480 ms | 0 ms | 676 ms | 363 ms (35% ↓) |
 | 2 | 56 ms | 12 ms | 0 ms | 57 ms | 11 ms (16% ↓) |
 | 3 | 16 ms | 7 ms | 0 ms | 16 ms | 7 ms (30% ↓) |
 | 4 | 19 ms | 10 ms | 0 ms | 19 ms | 10 ms (34% ↓) |
 | 5 | 27 ms | 9 ms | 0 ms | 28 ms | 8 ms (22% ↓) |
 | 6 | 59 ms | 11 ms | 0 ms | 59 ms | 11 ms (16% ↓) |
 | 7 | 42 ms | 8 ms | 0 ms | 42 ms | 8 ms (16% ↓) |
 | 8 | 30 ms | 3 ms | 0 ms | 30 ms | 3 ms (9% ↓) |

Savings generally scale with Razor Phase 1 duration since it now overlaps with the HTML call rather than waiting for it to finish.